The present invention relates generally to computer systems and more particularly to the management of directory objects in a directory service.
The network computing model, in which intelligent client computers are connected to multiple server computers, is quickly becoming the dominant computing model for enterprises, intranets, and the Internet. At the same time, the network computing model is itself rapidly evolving. As the network technology matures, networks of servers and clients have been and are continuing to replace systems of mainframes and terminals and other computing paradigms, which were once considered more advanced. Cost and productivity are among the primary factors driving the changeover to the client server network model. Relatively inexpensive servers and client computers and off-the shelf software applications are replacing expensive centralized mainframes and cumbersome custom developed software applications.
The network computing model purportedly offers a robust computing environment in which multiple servers provide redundancy to a multitude of clients. However, as the deployment of networks has gained momentum, it has brought its own set of issues. Instead of providing a centralized location from which every aspect of the network can be controlled, computing power is decentralized requiring configuration and control over computers at a number of disparate physical locations. As a result, maintaining the computers and the applications they run at the disparate locations can involve substantial costs.
As the network computing model continues to take hold, computer networks have become an increasingly important tool for users to share access to system resources such as programs, data, printers, and so on. Many attempts have been made to provide a structure for sharing access to resources in a computer network. A particularly important development in structuring access to system resources is the hierarchical directory service. One of the more significant attempts to standardize a directory service is the X.500 directory standard (also known ISO 9594).
Although the X.500 standard offers a basic structure for directory services, it does leave some issues unresolved. Extensibility and providing for a common user interface are among the issues. Adding new resources to the network environment has required making extensive adjustments throughout the network at various client computers and server computers, rather than at a single point. In particular, adding a new resource to the network often requires an administrator to physically go to each computer on the network and reconfigure the computer to enable it to recognize the new resource, e.g., to display attributes of the resource in a user interface. Of course, making all of these adjustments to the system at multiple locations increases the likelihood that an incorrect adjustment will disrupt the operation of the network. In other words, extending the network system has incurred a high cost and created the likelihood that resource extensions would be disruptive to the operation of the network, resulting in lost productivity to the network users.
Moreover, a user interface must be provided for network users to access and view attributes of the network resources. However, in a network with a large number of users, separately reconfiguring the user interface on each user""s computer would be costly and time consuming. Ideally, when a new resource is added to the network and made available to the network users, e.g., through a directory service, all user interfaces should instantly recognize the resource without the need to reconfigure the user interface.
For example, if an administrator wants to add a new scanner resource to the network and make that scanner resource available to all of the network users, information about the scanner should be published in the directory. Thereafter, users could locate the scanner by way of the directory and have the capability to view attributes of the scanner via a user interface. However, if the directory does not support scanner resources, the administrator would have two alternatives: (1) fit the scanner attributes into an existing resource type (alternately referred to as an object class), such as a printer object class; or, (2) define a new object class tailored to scanners. Potentially, alternative (2) may not even be available. In that case, the administrator would have no choice other than to add the new resource as an existing object class.
Under the first alternative, the administrator would add the scanner resource to the directory under the closest available object class, e.g., a printer class. Hence, a user would view the scanner as if it were a printer, even though there may not be complete overlap of attributes. If the new resource closely matches an existing object class, this alternative is satisfactory. However, when no suitable object classes are available for a new resource, this alternative has obvious shortcomings.
Under the second alternative, the administrator would define a new object class to support the scanner resource. Hence, a user should view the scanner as if it were a scanner. But, to view the scanner resource as a scanner, the administrator would have to make extensive changes throughout the network so that each user""s user interface would be able to display all of the attributes of the scanner resource. For example, the administrator would have to make changes to the object definitions structure (i.e., the schema) defining the new object class, the computers of all users to provide them with user interface software that recognizes the new object class, and so on.
The cost of such changes are high as is the risk that an inadvertent error made while making the changes will disrupt the operation of the network. Instead, the changes to add the new resource and to add user interface information about the resource should be made from a central location and propagated throughout the network.
Thus, there is a need for an extensible resource sharing environment in a computing network in which user interface information can be propagated across a computer network.
The present invention addresses the need for an extensible common data access user interface by storing user interface information in a display database, preferably part of a directory service database, and then coupling that user interface information to the data it will display. The directory service database data to be displayed via the user interface information is in the form of data records of a predefined type stored on at least one of the servers. A second database, preferably part of the same directory service, is stored on the same or another server. The second database contains display records of display information that indicates how records of the predefined type are to be displayed. A group of display records is referred to herein as a display specifier. The predefined record type and the display record are coupled together, preferably by sharing a common naming convention, so that a workstation can display data records of the predefined type by locating the corresponding display record. Thereafter, when an administrator wants to modify or extend an interface, for example after the database schema is changed, changes are made to the display database and not the workstations. When data is then displayed on a workstation, the data""s display information is retrieved from the display database. Accordingly, changes or additions to the user interface data records are propagated to the workstations by way of the display record. Hence, display changes made in the display database are automatically propagated to all of the workstations without the need to modify each workstation individually.